Jan 94 Top 10
Volume Number: 10
Issue Number: 1
Column Tag: Think Top 10
Think Top 10 fi
By Kevin Irlen, Think Technical Support, Symantec Corp.
Note: Source code files accompanying article are located on MacTech CD-ROM orsource code disks.
This is a monthly column written by Symantec’s Technical Support Engineers
intended to provide you with information on Symantec products. Each month we cover
either a specific application of tools or a “Q&A” list.
Q. I’m trying to compile a simple “Hello World” example in C++, and I get an
“invalid declaration” on a line that reads “class ostream;” in file <2comp.h>.
What’s going on, and where did this file come from?
A. You’ve #includ’ed , but by reflex, you must have created a .c file...
Since the default translator for .c files is the C translator, just
ain’t gonna compile. The first place it violates C syntax is in the indicated line in
<2comp.h> which #include’s. Until you realize what’s going on
here, this can be pretty confusing! Save your file as a .cp file, and this problem
should disappear.
Q. How do I send my output to the printer using IOStreams? And I just want specific
output to go to the printer, not my users’ prompts and responses.
A. IOStreams works on top of the Standard Library console package, so cin is tied to
stdin, cout to stdout, and cerr to stderr. To echo stdout to a file or to the printer,
you still use cecho2file or cecho2printer. With the Standard Library console
package, separating output from the main console means simply creating another
console, using fopenc. The strategy is the same for IOStreams, the only trick is
tying the new console to a stream. This is done via a stdiobuf, as illustrated
below:
/* 1 */
#include
#include
#include
void main(void)
{
FILE *fp = fopenc();
stdiobuf fps(fp);
ostream os (&fps);
chide (fp);
cecho2printer(fp);
os << "This goes to hidden console & the printer" << endl;
cout << "This goes to the user." << endl;
}
Q. I’m trying to override the global operator new. But I get “multiply defined:
operator new(unsigned int) (myfile.cp, CPlusLib)”. What should I do?
A. There is really no such thing as “overriding” global operator new. You can
overload it by supplying a function which takes additional arguments beyond the
required size_t first argument, and you can provide a class with its own operator
new; but if you want to replace the global operator new(size_t) that is defined in
CPlusLib, then you’ll have to do just that -- replace it, and have your own
custom CPlusLib. (In other words, as far as the linker is concerned, operator
new is treated just like any other function.)
One interesting example of overloading global operator new is the “placement”
operator new provided by , which takes an additional void * argument
and simply returns that same argument. The purpose of this function is to allow
previously allocated storage to be used to hold a new instance of an object, while
retaining the constructor-calling action of operator new. (Here again, if for
some reason you wanted to “override” this function you would have to replace
it.)
Finally, the confusion about “overriding” may come from the fact that you can
override the “new handler” which is called when a memory allocation request
can’t be met. This is done simply by calling set_new_ handler with a pointer to
your “new handler” function.
Q. I have an abstract class with all pure virtual functions, including the destructor.
I do not define any of these functions, since they must be overridden in a derived
class. However, a get a link error telling me the abstract class’ destructor is
undefined. What’s going on?
A. Virtual destructors insure that the appropriate destructor gets called first for an
object whose class is not determined until run time.
/* 2 */
class A
{
virtual ~A();
...
};
class B : A
{
~B();
...
};
void main(void)
{
A *a;
...
a = new B;
...
delete a; // B's destructor called first.
...
}
They do not change the fact that destructors are then called for each base class
when the derived class object is being destructed. Declaring a destructor pure virtual
does not change this fact either. The pure specifier here, as with any function, forces
the class to be abstract, and forces the derived class to define a destructor of the same
type; but unlike with “regular” functions, it does not, and cannot bypass the need for
the abstract class’ destructor actually to be able to called.
Q. All I did was add IOStreams to Starter++.π and I’m crashing before I get to
through application initialization.
A. IOStreams allocates memory during static initialization. The default 200K
partition used by the Starter project will no longer be sufficient. Increase it to
300K, and the problem should disappear.
Q. Do libraries’ “Set Project Type” settings have to match the project’s “Set
Project Type” settings exactly? E specially, what about Far Code and Far Data?
A. OK, here’s the whole deal...
Project Type: If the main project is an application, libraries must be
applications as well. This is because globals and jumps are going to be referenced off
of A5.
If the main project is not an application, libraries must be code resources. This
is because globals and jumps are going to be referenced off of A4.
Partition: Libraries’ settings are ignored.
Size Flags: Libraries’ settings are ignored.
Separate STRS: If turned on in a library, the main project must be built with
this option on as well.
(Separate STRS has no effect in C++.)
Far Code and Far Data: Some libraries explicitly test for these options, and
compile differently based on their being on or off. Obviously, you would need to use the
proper version of such libraries. The only THINK libraries that do this are oops and
oopsDebug (and oops++ and oopsDebug++), and we provide oopsFar and oopsDebugFar
pre-built (ditto for the ++ ones). For libraries that do not compile differently under
different FAR or NEAR options, there is usually no need to build FAR versions of them
in order to use them in a FAR project. However, as explained on pp.266-7 of the
THINK User’s Guide, you should segregate NEAR libraries from the rest of your code.
Finally, there are two cases where even segregating your NEAR libraries is not
sufficient, and one or more of your libraries will have to be changed to FAR.
1) THINK must put all jump table entries of a NEAR CODE library into the first 32K
of the jump table. Furthermore, if your NEAR CODE library calls out to a
function in the main project (or in another library), then that function’s jump
table entry must also be within the first 32K of the jump table. To provide a
mechanism for this, THINK will create NEAR jump table entries for ALL
functions in a segment containing a NEAR CODE library. Thus, a problem arises
if your combined NEAR CODE libraries require more than 32K of jump table, or
if, by putting other source files in the same segment as a NEAR CODE library, you
cause the first 32K of the jump table to be used up before all the libraries’ NEAR
entries can be placed: THINK will be unable to create enough NEAR jump table
entries and you’ll get ILLEGAL NEAR REFERENCE link errors.
2) Similarly, THINK must put all global data referenced by a NEAR DATA library
into the first 32K of the application’s global variable space. If a NEAR DATA
library references external global data, then the file where the external data is
defined must be in the same segment as a NEAR DATA library so its globals will
also be stored in NEAR global variable space. Thus, a problem arises if the
combined data of your NEAR libraries is greater than 32K, or if by putting other
source files in the same segment as a NEAR DATA library you cause the first 32K
of the application’s global variable space to be used up before all the libraries’
NEAR data can be placed: THINK will be unable to place all the NEAR DATA
properly, and you’ll get ILLEGAL NEAR REFERENCE link errors.
In C++, all class vtables occupy global data space, so the FAR project/NEAR
library problem can crop up if the library refers to classes that it does not define.
Q. We’re using SourceServer, and want to store our .rsrc files in the ProjectorDB
along with our source files. As usual, SourceServer adds a ‘ckid’ 128 resource
to each file, so we were worried that when we added the .rsrc files to a project
we would get ‘duplicate resource’ errors when we tried to compile. But we don’t.
Why?
A. If you take a look at the Resource Copier translator in ResEdit, you’ll notice that
it’s got a ‘SKIP’ resource. This resource contains a list of resource types,
which, as its name suggests, are to be skipped during resource copying. By
default, it contains a single entry, ‘ckid’. (Yes, this means you could add other
resources to the SKIP list; though I can’t think of a reason why you’d ever want
to...)
Q. I’m running out of memory when running and debugging my C++ programs. Until
I have more RAM, is there anything I can do to use the memory I have more
efficiently?
A. First of all, make sure you understand what your memory situation looks like
before compiling, and what it should look like once you’re successfully up and
running under the debugger. For example, on a Mac LC III with 4Mb RAM things
might look like this:
Before compiling:
System Software 1,100K
THINK Project Manager 2,048K
Free Memory 852K
After compiling, and running w/the debugger:
System Software 1,100K
THINK Project Manager 2,048K
Debugger 250K
Application 500K
Free Memory 102K
When memory is tight, you’ll have to strike a balance among these five pieces.
Clearly you want your System to be as lean as possible. Keep in mind that during
compilation the THINK Project Manager attempts to make the most out of your Mac’s
memory, and the most efficient use of its own partition, by allocating out of the
“MultiFinder temporary pool”, or free memory. Note that in the above example the
TPM’s partition has been reduced from the 4Mb default to 2Mb, leaving about 100K
free. This will produce better results than giving everything available to the TPM.
If you’re running out of memory while debugging, the solution is NOT to increase
the Debugger’s partition. Even though you’re in the Debugger, it’s still the compiler
that’s doing the work of evaluating expressions. Again, look to the TPM/free memory
combination.
If you’re running out of memory before even getting into the Debugger, try
holding down the option key while choosing Run. This resets the Debugger by clearing
all expressions and breakpoints. Also, double-check that the partition you’ve set for
your application isn’t greater than the amount of free memory!
Finally, here are two space/time tradeoffs that can help:
1) Don’t use precompiled headers. They improve compile time, but take up valuable
space in the TPM’s heap.
2) By default, both the THINK C and Symantec C++ translators are kept in memory
while the TPM is running. You can allow one or both to be swapped out, and save
some space at the expense of speed, by tweaking a bit in ResEdit. Open the
translator in ResEdit, and then open the ‘INFO’ resource. Scroll to the bottom and
switch the “Memory Resident
Q. I want to write some assembly language for my C++ project, but I can’t! The C++
compiler doesn't have an inline assembler and I can't figure out how to call my
C++ functions from THINK C. Is there no hope?
A. You can call a C++ function from within an inline assembler block in the same
way you would a C function: just JSR to the function. There is a slight
complication though: the C++ language implements its type-safe linkage by
“mangling” the name of functions and methods to contain the type information. So
to call a C++ function from C, you need to use its mangled name. You can get the
mangled name by turning on the “Generate MacsBug names” option in the
Symantec C++ options dialog and disassembling the file containing the function
whose mangled name you want. The mangled name will appear in a string at the
end of the function. For example, assume that foo.cp contains the function:
Translator” from 1 to 0.
Q. I’ve got the .o extension mapped to the .o Converter. Why doesn’t my .o file appear in
the Add Files... list?
A. In addition to having an extension for which there’s a translator, translators will
only accept certain file types. A .o file must be of type ‘OBJ ’. If your .o file has “been
around” (e.g. you downloaded it from an online service) it may have lost the ‘OBJ ’.
Q. I’m using your “Save Project as Text” and “Create Project From Text” scripts.
They work fine except for one small problem: they don’t restore my project’s settings.
A. This is indeed a shortcoming of these scripts. Unfortunately, the data structures
which hold the project settings don’t lend themselves easily to the “Save as Text”
approach. Here’s a straightforward script to run after running “Create Project from
Text” which allows you to copy the project settings from the original project to the
new one. Not quite as nice as actually saving the settings as text along with the rest of
the project, but it will fill the gap in many situations:
!coddexamplestart
/* 3 */
copy "Hard Drive:Proj Folder:newProj.π" to targetProjName
tell application "THINK Project Manager
tell project document 1
copy project type to projType
copy options block 1 to options1
copy options block 2 to options2
copy options block 3 to options3
copy options block 4 to options4
copy options block 5 to options5
close
end tell
open file targetProjName
tell project document 1
set project type to projType
set options block 1 to options1
set options block 2 to options2
set options block 3 to options3
set options block 4 to options4
set options block 5 to options5
end tell
end tell
!coddexampleend